home *** CD-ROM | disk | FTP | other *** search
- What are the general problems with hypertext?
- =============================================
-
- The current collection of some 20 hypertext programs, both for personal
- computers as well as mainframe computers, includes a number of obvious
- faults. In my mind, the design flaws seem to center on:
-
- ┌───────────────────────────────────────────────────────────┐
- │ - mouse selection - pictorial formats │
- │ - page framing - non-hierarchical structures │
- │ - database indexing - network browsing │
- └───────────────────────────────────────────────────────────┘
-
- Here's what I think is wrong with these concepts in hypertext.
-
- MOUSE SELECTION: One common misconception is that hypertext requires a
- ================ mouse. In graphic selection (pointing to segments of
- diagrams or drawings), a mouse is superb. However, for
- routine selection among a fixed set of objects (e.g.,
- keys on a keyboard, items on a list, levels in a
- display), the keyboard is from three to 20 times faster.
-
- To experienced users, the actions of fingers on a
- computer keyboard <FILE25 KEYBOARDS> more closely resemble
- parallel processing -- with key selection using fingers
- alone, being many times faster than mouse selection. That's
- why my vision of hypertext emphasizes keyboard selection
- over mouse selection in choosing among several hypertext
- branches.
-
- PICTORIAL FORMATS: Another popular misconception of hypertext is the
- ================= emphasis on windows, with flawed thinking about page
- layering and button linking.
-
- The first problem in pixel formats is page construction
- time. In the time required to create a suitable drawing
- construction time in pixel formats, you could create perhaps 100 ASCII
- format hypertext frames (text alone).
-
- Picture hypertext (pixel page formats) typically require
- 10-20 times as much disk space ASCII text. For example,
- storage space we recently shipped on three disks a large ASCII format
- hypertext system containing several thousand nodes, links,
- and screens. If instead we used window and pixel
- formats, the same three disks would have held less than
- 100 screens.
-
- Worlds of In the world of material suitable for hypertext (laws,
- knowledge specifications, ruling, depositions, articles), the most
- of such knowledge is in text format, not by pictures,
- diagrams, or graphics. While a picture may be worth
- 1,000 words, textual knowledge (e.g., law, medicine, and
- accounting) exceeds diagram-form knowledge perhaps by a
- ratio of 1,000,000 to one. <FILE54 KNOWLEDGE>
-
- Many PC users still have systems that are ill suited to
- the evolving operating systems and hardware required for
- pictorial hypertext. Standards in picture formats,
- memory/cpu requirements, and compatibility are not yet
- stable. For example, your 1989 scheduled PC-windowing
- today's computers hypertext system including the full implementation of
- OS-2 will probably require 4 megabytes of memory. In
- contrast, ASCII hypertext easily runs on a minimal
- current system (i.e, minimum 256k memory -- 10-megabyte
- hard disk).
-
- PAGE FRAMING: Another major flaw in many current hypertext systems is
- in organizing ideas into screen-size units instead of by
- idea units. Screen-size units inhibit link construction
- and also foster difficulties in button binding that
- idea-unit framing avoids. <FILE28 FORMAT>
-
- In link construction, I build branching points in
- link construction hypertext decision trees perhaps 10 times faster when
- linking directly to idea units instead of putting
- buttons on a screen. In addition, I can rapidly merge
- and divide my idea units in ways that are impossible to
- manipulate with screen-based hypertext. <FILE64
- METHODS>
-
- While appearing functional, the buttons in some systems
- have no binding to the ideas on the screen. For
- button flaws example, in Apple's HYPERCARD, if you place a jump
- button on a particular word to edit the text so that
- the marked word is moved, the button falsely identifies
- another word as the jump point to the original word. The
- branching methodology is not in any way coupled to the
- idea units. That's simply an invitation to dead-end
- pointers.
-
- NON-HIERARCHICAL Many implementations of hypertext have their roots in
- APPROACHES what has become known as "Xerox envy." The Xerox
- NOTECARDS system overemphasized the jump button and
- graphic screen formats while neglecting hierarchy and
- taxonomy features.
-
- lost in The current hypertext systems rooted in NOTECARD
- hypertext formats invariably provide a "lost in space" experience.
- Pictorial browsing systems easily fall into
- spaghetti-like labyrinths of links (great for game
- trekkies, but scarcely functional elsewhere). In
- contrast, ASCII hypertext with its central emphasis on
- obvious hierarchies and taxonomies is much better
- suited for both rapidly finding information and
- communicating the overall structure of the knowledge
- contained therein.
-
- DATABASE INDEXING: Hypertext centers on two ideas: indexing information by
- idea content and rapid access to such information
- regardless of the user's level of understanding.
-
- database or These goals cannot be achieved using conventional
- hypertext? database approaches. Yet, behind the flash of many
- hypertext systems, you'll find only database methodology
- of keyword searches and relational processes. There
- are several major problems inherent in database
- methodologies: words versus ideas, presumed knowledge,
- set intersections, and synonyms. <FILE23 PROBLEMS>
-
- indexing ideas? The process of indexing words simply does not index
- ideas. Ideas are larger units and hypertext systems
- that index ideas tend to be superior (in both usefulness
- and speed) to database approaches that index only words.
-
- relational or Databases use relational methods. These methods
- hierarchical presume a knowledge of the language of the field and
- access? usage of set intersection techniques with the language.
- If you are unfamiliar with either, you simply can't
- extract information from the system. That's the reason
- why hypertext exists -- it overcomes many of the
- deficiencies found in relational databases.
-
- NETWORK BROWSING: One of the more fanciful approaches to hypertext
- ================= browsing consists of automatically displaying on the
- screen the network of relationships between items within
- the system. This approach presents problems in
- utilizing the capabilities of the hardware, the user,
- and the system.
-
- limits of In a typical network of 30 screens, there are a
- displays possible 900 links between such items. Displaying this
- network on a screen (or most subsets of this) provides
- little user understanding of the system. Neither the
- screen, the operating system, nor the user are matched
- to the task.
-
- Whereas some hypertext systems use visible network
- the heart of displays, I believe the PC-Hypertext approach offers
- hypertext better methods for both browsing and communicating the
- structure of the knowledge within the hypertext system.
- At the core, that's the art and craft of hypertext
- regardless of the hardware and software -- communicating
- and confirming structure with each piece of information.
-
- As for a conclusion, the design of all software (including PC-Hypertext)
- focuses on tradeoffs <FILE17 DESIGN>. From my viewpoint, until the
- capacities of both floppy and hard disks are increased, this format of ASCII
- hypertext has many advantages over graphic forms of hypertext.
-
- Neil Larson 1/16/88 files22
- 44 Rincon Rd., Kensington, CA 94707
- Copyright MaxThink 1988 -- Call 415-428-0104 for permission to reprint
-